Skip to main content

ANALYSIS: Process Inventory

Kibana Dashboard: [INVENTORY] Processes

What is this baseline?​

The associated Kibana dashboard represents the baseline inventory of process executables observed within the DAL.

  • A process entry consists of:
    • process.executable (primary identity)
    • One or more associated host.hostname values
    • One or more associated user.name values
    • A derived file.name (when extractable)
  • Each row answers:

    "Was this process observed present in the baseline inventory?"

  • This is not an EDR timeline or process tree view:
    • No parent/child relationships
    • No execution frequency or duration
    • No command-line history
  • A single corroborated execution is sufficient to add a process to the baseline.
How the baseline is built
  • Entries are deduplicated by process name
  • Executables are normalized as full paths when available
  • Processes are added when observed on a host correlated to the DAL
  • @timestamp reflects when the process executable was last observed and written into the baseline

Data Prerequisites​

note

If any of these are missing or incorrect, the baseline is unreliable.

1. DAL / HOME_NET must be correct​

  • Derived from Zeek and/or Suricata HOME_NET
  • Used to determine which hosts to use process data from
  • Incorrect DAL → missing hosts and incomplete process coverage

2. Required telemetry sources (at least one)​

  • Sysmon (process creation)
  • Winlogbeat Security (Event ID 4688)
  • Auditbeat (process)
  • Endgame (process telemetry)
  • Metasponse
    • Survey Collector
    • 262 - [🔥Volatile Info] Processes

NOTE: Process visibility is host-telemetry driven.
Missing or uneven endpoint coverage will result in significant gaps.

Basic Analysis Workflow​

1. Baseline sanity check​

Validate expected process population:

  • Common OS and framework binaries dominate
  • Known line-of-business applications appear
  • Process count aligns with host count and role

Large process counts are normal; focus on what's unexpected, not volume.

2. Long-tail analysis (primary value)​

Focus on rare or low-context executables

  • Executables seen on a single host
  • Executables run by unexpected users
  • Non-standard install paths
  • User-writable directories (AppData, Temp, Downloads)

Key questions

  • Legitimate application or admin tool?
  • Installer or update artifact?
  • Living-off-the-land binary misuse?
  • Custom or unauthorized executable?

Validate against:

  • Known software inventory
  • Expected admin tooling
  • Vendor documentation
  • Host owner or administrator confirmation

3. Host and user correlation review​

Processes spanning many hosts

  • Usually OS components or enterprise software
  • Unexpected spread may indicate lateral tooling

Processes tied to single users

  • Normal for user-space apps
  • Suspicious if the user context is privileged

SYSTEM / service context

  • Expected for core services
  • Investigate if paired with non-standard paths

Correlation anomalies increase priority; they are not proof by themselves.

4. Export for reporting and diffing​

note

Reporting and documentation requirements are determined by the Mission Element Lead/Crew Lead

Common exports

  • Full Inventory table (CSV)
  • Executables by host
  • Executables by user

NOTE: These exports represent the declared process baseline for the mission period.

5. Enable baseline deviation detection rule​

caution

Enabling too early guarantees noise - it will alert on ALL new inventory additions after enablement.

tip

Detection rules can be managed in Kibana under Security → Rules

Rule: [262][Inventory] New process executable added to baseline​

  • Detection logic:

    Alert when a new process executable is added to the baseline inventory

  • Only enable after:
    • Baseline window is complete
    • Expected software is fully observed
    • Long-tail process review is finished
  • Ongoing alert tuning:
    • Whitelist known installers and update artifacts
    • Suppress expected admin tooling
    • Validate whether the executable represents new capability or expected change

This rule is intended to catch:

  • Malware binaries
  • Unauthorized tools
  • Persistence mechanisms introducing new executables